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(57) Abstract 

A system and method for providing computerized, knowledge- 
based medical diagnostic advice. The medical advice is provided to the 
general public over a neiworic, such as a telephone network with the 
use of a telephone or the Internet with the use of an Internet access 
device. Alternatively, the medical advice can be provided to a patient in 
a stand-alone mode by use of a computer. The invention utilizes a list- 
based processing method of generating and executing diagnostic scripts. 
For the purpose of diagnosing a health problem of a patient, medical 
knowledge is organized into a list of the diseases to be considered. Each 
disease on the disease list includes a list of symptoms that is checked in 
a patient. Each symptom on the symptom list is then further described 
as a response to a list of one or more questions asked of the patient about 
the symptom. This triply-nested list structure is converted by suitable 
data structure iransfomiations into a script that is stored. When a patient 
requires diagnosis, the script is played back as a sequence of questions. 
The responses of the patient are analyzed and converted into symptoms. 
The syntpioms are accumulated into diseases. Finally the diseases are 
selected and reported as a diagnosis. 
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CORfiPlTTERBZED RffEDiCAL DBAGC30STIC SVSim UTILOZIBG UST BASED PROCESSIKG 

Bacttorounrf of the Invention 

Field of the Invention 

The present invention refates to computerized medical diagnostic systems. More specifically, the invention is 
directed to a computerized system for time-based diagnosis of a patient's complaint by use of dynamic data structures. 
Description of the Related Technoloov 

Health care costs currently represent a significant portion of the United States Gross National Product and are 
rising faster than any other component of the Consumer Price Index. Moreover, usually because of an inability to pay 
for medical services, many people are deprived of access to even the most basic medical care and information. 

Many people delay In obtaining, or are prevented from seeking, medical attention because of cost, time 
constraints, or inconvenience. If the public had universal, unrestricted, and easy access to medical information, many 
diseases could be prevented, likewise, the early detection and treatment of numerous diseases could keep many patients 
from reaching the advanced stages of illness, the treatment of which is a significant part of the financial burden 
attributed to our nation's health care Systran. It is obvious that the United States is facing health-related issues of 
enormous proportions and that present solutions are not robust. 

Previous attempts at tackling the heahh care problem have invoh^ed various forms of automation. Some of these 
attempts have been in the form of a dial-in library of answers to medical {|uestions. Other attempts have targeted 
providing doctors with computerized aids for use during a patient examination. These methods invohre static procedures 
or algorithms. What is desired is an automated way of providing to a patient medical advice and diagnose that is quick, 
efficient and accurate. Such a medical advice system should be modular to allow expansion for new types of medical 
probtems or methods of detection. 

One way of conducting an interview of a patient includes medical diagnostic scripts. What is needed is an 
efficient method of representing the medical knowledge ol experts in their specialties in a script format. The scripts 
should utaize dynamic structures to quickly and efficiently reach a diagnosis of the patient. 

Summary of the Invention 

List-Based Processing is a method of diagnosing diseases that works by arranging diseases, symptoms, and 
questions into a set of nested Disease, Symptom, and Ouestion (OSQ) fists in such a way that the Bsts can be processed 
to generate a dialogue with a patient. Each question to the patient generates one of a set of defined responses, and 
each response generates one of a set of defined questions. This estabHshes a dialogue that efoiis symptoms from the 
patient. The symptoms are processed and weighted to rule diseases in or out. The set of ruled m diseases estabfishes 
the diagnosis. A List-Based Processing system organizes medical knowledge into formal structured Bsis or arrays, and 
then applies a special algorithm to those lisis to automatically select the next question. The responses to the questions 
lead to more questions and ulttmatehr to a diagnosis. 
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In one embodsnent of the mvention, there is b computerized diagnostic method, comprising the steps of providing 
to a computer a Gst of diseases, each disease associated with a fist of symptoms, and each symptom associated with 
a list of questions; repetitively asSting questions to eficit responses, the responses estabEshing symptoms, each estabGshed 
symptom contributing a weight to a disease; and determining whether the accumulated weights for a disease reach or 
pass a threshold so as to declare a diagnosis. 

The medical advice system also Includes a geographic-based list of differential diagnoses in the population in 
which the patient resides, which, when processed by the list-based processor, is turned into a patient specific differential 
diagnosis. The system, also inchides a table in whkh the frequency of the diseases is kept to aHow the system to 
evaluate the patient using the probabilities or incidence of diseases in the population in which the patient resides. The 
system may also give patient specific and context sensitive recommendationlsj for the laboratory test(s) of choice and 
the imaging modality of choice to further help define a diagnosis. The system may invoice a **re~enter" function to aOow 
for the laboratory test(s) of choice and the ffnaging modality of choice to be performed and then the results to be 
conveyed to the patient, the patient's heahh-care ghrerls) andlor any other desired entity. The system may invoke the 
"re-enter" function to allow a patient to perform physical examination maneuvers (on self or via an assistant) and re- 
consult the system to further refine the diagnosis. 

Brief Descriotion of the Drawings 

Figure la is a btock diagram illustrating components of a presently preferred embodiment of the computerized 
medical diagnostk and treatment advice (MDATA) system of the present invention; 

Figure lb is a block diagram ilhistrating components of the user/patient computer of the MDATA system shown 
on Figure la; 

Figure 2 is a block diagram illustrating a set of processes, ffies, and databases utilized by the system of Figure 

la; 

Figure 3d is a diagram of an off-line medical diagnosis saipt (MOS) generation process used in producing a script 
file for the MDS database shown in Figure 2; 

Figure 3b is a diagram illustrating a possible hierarchy of the DSQ lists for a script at two different time 

intervals; 

Figure 4a b a flow diagram of an assign (Bseases portion of the "collect end organize medical bnowtedge" 
process shown in Figure 3a; 

Figure 4b is a flow diagram of a capture disease knowledge portion of the 'collect and organize medical 
knowledge process" shown in Rgure 3a; 

F^ure 5 is a flow diagram of the "scrqit compfler* process shown in Figure 3a; 

Figure 6a is a block £agram showing a configuration used during operation of the diagnostic scr^tt engine; 
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Figure 6b is a block diagram showing a set of structures and Inputs used during operation of the scrgit engme 
and the outputs produced by the MDATA system; 

Figure 7 is a top-level flow diagram of a user process for the MDATA system of Figure 1; 

Figure Ba is a ftow diagram of the "diagnostic script engine* process used m perforrrang the on-Rne interview 
process shown in Figure 7; 

Figure 8b is a flow diagram of the "distribute advice' process shown in Figure 8a; 

Figure 9 is a flow diagram of portions of the "DSQ hst script engine" process shown in Figure 8a for list-based 
processing; 

Figure 10 is a block diagram showing a portion of the lists utilized during operation of the DSQ list script engine 
shown in Figure 8a; 

Figure 11 is another flow diagram of the °DSQ list script engine" process shown in Figure 8a; 
Figure 12 is a flow diagram of the "select symptom" (select symptom to be considered) process identified in 
Figure 11; 

Figure 13 is a flow diagram of the "handle response" (process response from the user) process kfentified in 
Figure 11; 

Figure 14 is a flow diagram of the "update disease lists" (update scores in disease temp Est based on updated 
symptom list and erminate diseases ruled-in or ruled out) process identified in Figure 11; and 

Figure 15 is a high-level flow diagram of an ahernative embodiment for generating medical advice or a diagnosfe 
in the MDATA system of Figure la. 

Detailed Description of the Preferred Embodiment 

The following detailed descrqition of the preferred embodiment pre^ts a descriptbn of certain spectfic 
embodiments of the present invention. However, the present invention can be embodied in a multitude of different ways 
as defined and covered by the claims. In this description, reference is made to the dravrings wherein fike parts are 
designated with like numerals throughout. 

For convenience, the discussion of the preferred embodiment will be organized mto the foBowmg principal 
sectbns: System Overview, Medical Diagnostic Scripts, Knowledge Capture Detafc, Script Generation DetaBs, Script 
Execution Details, and Advantages of List-Based Processing. 

I. System Overvww 

A Medical Diagnostic and Treatment Advice (MDATA) system b a computer system that conducts automated 
interviews of patients for the purpose of estabftshtng a medical diagnosis. To conduct the interviews, MDATA uses a 
database of Medical Diagnostic Scripts (MDS). Each MDS contains the data and commands needed to interview a patent 
for a spectfic medical conditbn end to output a diagnosis. Scripts are supported by other MDATA databases of dbeas», 
symptoms, treatments, medications, specralists - in short. aO information required for nwdical diagnosb and advice. 
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Symptoms can be defmed as 8 piece of hbtorical infonnatran, a piece of infonnetion eBchad from a physical examination^ 
e.g., physical signs usually from a self-examtnation, the results of a labwatory test, or the resuhs of an imaging modafity 
of choice. 

Referring to Figure la. a block diagrmn of a presently preferred embodenent of the MDATA system 100 w3l 
5 be described. The MDATA system 100 includes a network 'ctoud" 102, v»hich may r^resent a local area network (LAN), 
a wide area network (WAN), the Internet, or another connection service. 

The MDATA programs and databases preferably reside on a group of servers 108 that are preferably 
interconnected by a IAN 106 and a gateway 104 to the network 102. Alternatively, the MDATA programs and 
databases reside on a single server 110 that utifizes network interface hardware and software 112. The MDATA servers 
10 108/110 store the disease/symptom/question (DSQ) lists descr'Aed heremb^w. 

The network 102 may connect to a user computer 116, for example, by use of a modem or by use of a 
network interface card. A user 114 at computer 116 may utilize a browser 120 to remotely access the MO ATA 
programs using a keyboard andfor pomting device and a visual display, such as monitor 118. Alternatively, the browser 
120 is not utilized when the ftltDATA programs are enecuted in a locelmode on computer 116. A video camera 122 may 
15 be optionaDy connected to the computer 116 to provide visual input, such as visual symptoms. 

Various other devices may be used to conimuntcate with the MDATA servers 106/110. If the servers are 
equipped with voice recognition or OTMF hardware, the user can communicate with the MDATA program by use of a 
telephone 124. A telephonic embodiment is described in Applicant's copending application entitled "Computerized 
Medical Diagnostic and Treatment Advice System," l).S. Serial No. 08/176,041. which is hereby incorporated by 
20 referoice. Other connection devices for communicating with the MDATA servers 108/110 tncbida a portable personal 
computer with a modem or wireless connection interface, a cable int^face device 128 connected to a visual display 130, 
or a satelthe dish 132 connected to a satellite recehrer 134 and a television 136. Other ways of afiowing convnunicat'ton 
between the user 114 and the MDATA servers 108/110 are envisioned. 

Referring to Figure lb, a diagram of a presently preferred user/patiant computer shows several possible 
25 interconnections to the network. To "play' a script, a special program called a Script Engine is used, which reads e MDS 
file and uses its codes to perform interview actions, such as outputting a question to a patient and inputting an answer. 
The scripts also collect the answers from the patient, evaluate the answers, issue a diagnosis, and update the patient's 
medical record. The scr^t engine preferably restdes in the user computer. Ttie script engine may be stored on the hard 
drive or CD-ROM, and is baded into the main monory or a cache for execution. 
30 The components of a presently preferred computer 116, utiGzed by a user 114 of the computerized MDATA 

system 100 of the present mventton, are shown in F^ure lb. Alternatively, other devices for conducting a medical 
interview, such as those shown \n Figure la. can be utSized in place of the computer t16. 
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ThB computer 102 mcbdes a phirality of components within an enclosure 1 1B. A telephone line lOB interfaces 
the public telephone network 158 to the computer 116 via a modem 160. The telephone neiworh 158 may connect to 
the network 102, which has connections with the fiftOATA system serverfs) 108/110. Altemathfely, the user may 
connect to the network 102 by use of a network interface card 164. 

Throughout this document, the words user end patient are used mtercbengeably. However, it will be understood 
that the user may be acting as a prony for the patient. If this is the case, (he user is registered as an assistant for 
the patient. 

The hardware and system software are assembled with two basic concepts in mind: portabifity to other 
operating systems and the use of industry standard components. In this way, the systm can be more flentbte and wDI 
allow free market competition to continually improve the product, white, at the same time, decreasing costs. While 
specific hardware and software may be referenced, it wiO be understood that a panoply of different components could 
be used in the present system. 

The computer 116 preferably is a personal computer with an intel Pentium microprocessor 170. Other 
computers, such as an Apple fWacintosh, an Amiga, a Digital Equipment Corporation VAX, or an IBM mainframe, could 
also be otifaed. The modem 160 or the network interface card 164 connect to an industry standard architecture (ISA) 
or a peripheral component interconnect (l>CI) bus 162. The bus 162 interconnects the microprocessor 170 with a 
phirality of peripherals through controller circuits (chips or boards). 

The computer bus 162 has a phjrality of peripherals connected to it through adapters or controllers. A video 
adapter board 172. preferably at SVGA or better resohitron, interconnects to a video monitor 118. A serial 
communication circuit 176 interfaces with a pointing device, such as a mouse 178. A paraBel communication ckcuit may 
be used in place of circuit 176 in another embodiment. A keyboard controller circuit 180 interfaces with a keyboard 
182. A 500 Mb or greater hard disk drive 184 and an optional CD-ROM drive 186 are preferably attached to the bus 
162. The hard disk 184 stores database files such as the patient files, other MOATA fSes, and binary support files. 
The CD-ROM drive 186 also stores database files, such as files for the patients usmg the computer 116, and binary 
support fdes. 

A main memory 190 connects to the microprocessor 17a tn the presently preferred embodsnent, the computer 
116 preferably operates under the Windows 95 operating system 192. The memory 190 executes a diagnostic script 
engine 194 and a disease/symptom/question fDSO) fist script enghe 196. The script engine software is wrrtten in 
Borland De^hi Pascal, version II. 

Referring to Figure I a set of processes, f3es, and databases utilized by the R/TDATA system 100 wBI be 
described. Eacept for the script engine process, the MDS database, the Imaging Modality database, and the Laboratory 
Test database, which are descra»ed hereinbelow. these processes, f&s, and databases were descrOted in AppGcant's 
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, copending appKcation enthled "ComputerizBd Medical Diagnostic and Treatment Advice System," U.S. Serial Bo. 
08/176,041. 

The MOATA system 100 utilizes several principal processes and related databases. A set of patient login 
processes 210 is used by the system 100 to identify a patient who has previously registered into the system in one of 
5 three ways: 1) by prompting for a patient identification number (PIM); 21 identify an assistant who has previously 
registered into the system by prompting for an assistant identification number (AIM); 3) identity a patient, having an 
assistant, who has previously registered into the system by prompting for the patient identification number. A set of 
processes 212 are used to register a patient or assistant. If the user b the patient, a patient registration process is 
used by the system to register new or first tffne patients. II the user is not the patient, an assistant registration process 

10 is used by the system to register new or first-time assistants. Then, if the patient is not already registered, an assisted 
patient registration process is used by the system to register the patent. 

Once a user has logged in or registered, the system provides a choice of processes. The prenary process of 
concern m the current embodiment is the Diagnostic process 220 that performs a patient diagnosis. The evaluation 
process 220 accesses a laboratory test of choice and imaging modatity of choice database to recommend the appropriate 

15 tests m this patient at this point in time and a treatment table 250 to obtain current treatment information for a 
particular disease or diagnosis. In another embodiment, other choices are added to access other medical information 
processes. 

Associated with these processes are a patient and assistant enroltmsnt database 240, a consultatbn history 
database 242, a patient response database 244, a medical history objects database 246, a patient medication database 
20 248, a pending database 252, a patient medical hstory database 254, a medical diagnostic scripts imS) database 258, 
an imaging modality database 258, and a laboratory test database 260. 

n. Medical Diapnostic Scripts 
A Medical Diagnostic Script (MDS) b a progranmied dialogue with a patient for the purpose of generating one 
or more diagnoses of the patient's condition. Developing an (VIDS invohfes several steps such as capturing the medical 
25 diagnostic Etnowledoe, efipressing it in terms that a patient can understand, arranging it into a useful sequence, compiling 
it into 3 playable script, testing it, configuring it for a specific communication medhim, embedding it into a coflection of 
other scripts and support databases, and packaging it for use by the patiant. 

Iftfriting a scrtpt" b considered to mean the early steps of capturing the medical hnowledge and processing it 
into a log'xal question stream that ultmiatety leads to a diagnostic conclusion. Obviously, only a physician experienced 
30 in diagnosing a specific set of diseases can perform these steps, and the MDATA system has developed several 
automated methods to support themi 

The invention preferably utSizes one particular method, called 'fist-based processing," which begins with ffsts 
of dheases. symptoms, and questions. These 5sts are then processed into a playabte scr^t using a rist-i)ased script 
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development tool Using the script development tool, the author can write and edit the source saipt. conqiile it into a 
playable script file, play the script back, and set various script options to eKercise, evshiate. and fine-tune the script. 

A list-based script consists of a specially formatted text file in which the author provides the etenumts of the 
script in the form of several lists. The top list is a list of diseases which the script wiO consider. For each disease, 
the script lists tho symptoms and their weights. For each symptomt the author provides a list of questions and their 
weights that wiO elicit the symptom. For eech question, the author provides multiple tut objects, including a preamble 
text that introduces the questbn. After aU of the Bsts have been prepared for a script, the neit step is to -compite' 
the script. Le. to convert h into a specially encoded script file that can be played bach, or 'run." for a patient. To run 
a script in the development phase, the script development tool selects a suitable next disease and a suitable next 
symptom for that disease. It displays the question text and warts for a reply from the patient. Based on the patient's 
response, the script development tool updates the disease scores and continues with the next symptom. The script stops 
when some condition (set by the author) is reached, such as the first disease bebig ruled si as a diagnosis, or afl diseases 
having been considered. 

During the development phase, the script author can set various "options' that wiO change the way the script 
selects the next disease and the next symptom, and how long the script wHI run. This option feature lets the author 
experiment with the script to find the best settings. 

The three main phases of a script, therefore, are: 1) knowledge capture, 2) script generation and 3) script 
execution. The script author utOizes all three phases in the creation and testing of a script. A patient utilizes the script 
execution phase during run-time use of the MOATA system 100. 
PHASES OF A SCRIPT 
t. Knowledee Capture 

The knowledge capture phase inchides aU of the tasks needed to extract from a medical expert the knowledge 
about diagnosing a given disease and reducing that knowledge to some form useful in generating a script. The phase 
typreaHy begins with a director of script development expressing a need for a script lor diagnosing a disease such as 
IWalaria. It continues with tasks such as defining the scope of the script, researching medical texts, interviewing authors 
and other experts, formatting the question and response sets, establishing the question sequence, and. if an automated 
bnowbdga capturing tool is vsei, running the question flow in a test setting. This phase ends with a set of source 
documents, possibly automated, that (at least) contams aU of the information needed to write a script that can correctly 
diagnose the disease. e.g.. Malariamot Malaria when it is fed test responses for a patient that does/not have Malaria, 
i^othing is known at this pobit about the ultimate form of the script, the platform on which it wiH run. or even the 
natural language it wH be usuig to communicate with the patient. 
2. Script GansTBtioB 
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In the script generation phase, the script is generated as a relathrely small diagnostic algorithm captured in 
software. In this phase, the goal is to let the script be an automated representstion of the author's approach to 
diagnosing a disease or other medical problem, such as Malaria. The script contains data and processes to produce a 
good first question, to weigh the response, to use the response to generate another question, and so on until the script 
5 can finally teQ its caller that the responses indicate Malarra or Not Malaria, and the associated level of confidence. 

Note that a script is not a stand alone program that can be run for a real pat^t. The script preferably only 
knows about a single chief complaint, such as Malaria, and does not diagnose other medicat problems such as Gout or 
Asthma. 

This script is destined to become one of approximately 40.000 scripts in the Script Database, in much different 
10 form and format. The script now has to be translated into the appropriate human tarquage (German. Spanish), 
supplemented with appropriate error handling mechanisms, generated into the appropriate programming language (C'^-^. 
Java, HTML), formatted for the appropriate target medium (PC, Mac, Telephone, LAN, WAN, Internet), and Enked to the 
Support System (databases, meta functions, patient records, session logging). 

Next, the script undergoes extenswe testmg in a testbed that feeds the script various canned sets of patient 
15 responses, with known acceptable diagnoses, to verify that the script does generate the appropriate output. 

Finally, the script is ready to be installed into a productbn system. It may be stored into a massive Script 
Database, or packaged into a set of scripts to be written to a CD ROM or shipped via the Internet to a hospttal. 
Whatever the form of the script library used, the scr^t wtO have to be indexed and registered will be with the Script 
Manager software. At the end of this phase, the script is at last part of an official, running medical diagnostic systnn 
20 that can be used on real patients for real diagnoses of real problems. 
3. Scropt Efleces^isin 

In the script enecution phase, the script is actually executed, sooner or later. Of course, a session with a 
patient does not start with a diagnostic script on Malaria. A medical diagnostic system open to the general public 
obvbusly has a number of adminhtrathre tasks to perform before it gets down to any medicat diagnosis. Rrst of aB. 

25 it does not want a patient acutely deteriorating whOe we ask for a password and Social Security Number. So the 
system most fikely first runs the Emergency Room (£R) subsystem for anyone who logs on to the KflDATA system. The 
ER subsyston consists of a few dozen scripts that determme whether the patient has any fife threatening conditkm that 
needs immediate *'first aid" therapy or advice. "Is thb a medical emergency?', "Does the patient have an airway?". "Is 
the patient bleeding?" are some of the questions the ER subsystem a^s. 

30 After the system weeds out the emergency cases, the system can slow down to identify the patient and 

determine the Chief Complaint(sl. Then the system invokes the Script Routing subsystem, whose job b to determme the 
patient's general problem area. Based on this information, the Script Routing system next selects a soiuence of top-level 
scripts that are appropriate to the patient's Chief Complaint. For example, for fever, after the more obvious scripts for 
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Appendicitis. Intestinal Flu. Food Poisoninfl have indicated "Wo Diagnosis." the Rooting script My decide to try 
MaJaiia. tiow, at last, the sample Malaria scr^t we have deveteped in this document is played. 

Scripts are not programs that run themsehres. Scripts are data streams that are run by a "script engine" that 
searches the script for the next question to ask of the patient, and formats the question for transmission (to a screen 
a telephone line, or an Internet site). The patient responses ar. also captured by the script engine, fonnatted for the 
scrvt. and used to select the next question from the script. This interplay of the script and its script engine may 
cDns,der the patient's medical record, the formation provided so far during this sesshm. and even some meta functions 
.0 determine the next question. At the end of the scrip,, the process returns control to the Tropical Dbease RoutinB 
Scnpt and says, in effect, "this patient's responses indicate Malaria Falciparum with a weight of 1350 out of 1000 " 
or "this patient's responses only add up to 420 out of 1000, so I rule out Malaria." The Routing script that cafled the 
iWalaria scrip, in the first place may now decide to access another diagnostic script, or may decide to return to its caBer 
some response such as "the patient's responses indicate only a 275 / 1000 likelihood of having any tropical disease " 
SCRIPT FEATURES 
Tima-Bssed Oiaenostic Scripts 

The rm,e.Based Diagnostic Script concept extends the DSO diagnostic scripts in the time dimension. Instead 
of just one diagnostic script, the script author now submhs several scripts, e.g, one for each hour into the disease 
process. Scripts are generated at an elapsed time from the beginning of symptoms, according to the best judgment of 
the author. For example, a myocardial infarction script would use one hour or less as an interval. whBe malaria would 
not. At run time, the diagnostic system uses the diagnostic scrip, closest to the patienrs case. The script has hnpOed 
symptoms that add extra weight to diseases that match the predicted pattern. 

The system asks the pathmt when the symptoms.started. and, partbUy based on that information, selects the 
appropriate script from the time-based set of scripts. Once the right script is selected, the script is executed. That is. 
each script of a set of time-based scripts may have somewhat different symptoms and weights, so that the author seti 
up tine-based symptoms with extra weights for those diseases whose time-pattern matches the patient's. These weights 
are automatically added by the scrip, engine as i, runs. Note tha, these .ime-based symptoms wiB be Implied Symptoms, 
descrdied hereinbelow. 

Each algorithm author must compose, assign, or calculate the questions and the appropriate vahies at (for 
instance) each hour as the disease progresses. Then, when the patient consults the system, one of the first questions 
,0 ask is "When (or how tong ago) did you, symptoms begin?" Then that patient wiB interact with ,he script tha, b 
dosest to the lapsed tme since the symptomsls) began. 
Implial Symptoms 

Note that a "symptom" is defined as any data item known about a patien,. directly or indirectly, mchiding name, 
age. gender, and so forth. An Implied Symptom is a symptom tha, is established based on the presence or-absence of 
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one or more other symptoms The bnpGed Symptom concepts allows the script author to tell the script engme that any 
given symptom (or set of symptoms) implies or denies one or more other symptoms. This lets the author embody rea^ 
world relationships into the List-Based script, which, in turn, lets the LB Engine make logical inferences that eEminate 
superfhious questions from the list and make the scr^t more focused. 

As an obvious eitampfe, a patient who is a man does not have to be asked questions related to the female 
reproductive system. A human doctor knows this impticitty, but the scr^t engine needs to be totd. The scr^t author 
ssnply makes a bst of symptoms in the form: 

IF Symptom A THEN Symptom B. 
For example: 

"patient is mate* knplies "patient is NOT female/ and 

"patient had Appendectomy" impEes "patient has no Appendix." 
Using the togical operators such as mu, OR or NOT, it is possible to build quite complicated symptom relationships that 
are triggered by relathrely few questions. 

bnplied Symptoms are listed in the source script as a table of "IF A THEN B" type statements. Whenever the 
engine receives a new symptom from the patient, it also checks the Imp&ed Symptom table to see if any other symptoms 
are htplied. 

Synergistic Symptoms 

Synergistic Symptoms are symptoms that indicate that, in any given patient, a certain set of other symptoms 
is present that have special diagnostic signifkance when they occur together. In a DSQ List-Based source script, each 
symptom has a certain specific weight toward diagnosing a disease, but the presence of a certain set may traid extra 
weight toward a diagnosis. For example, Malaria is classically diagnosed starting with the presence of Chills, Fever, and 
Sweating (which are caused as the Malaria-causng agent goes through its r^roducthra cycle m the blood). The presence 
of Chills or Fever or Sweating separately would probably not necessarily suggest pursuing Malaria as a diagnosis in a 
patient, but the assertion of aB three of these symptoms should trigger an inquiry about Malaria. The concept of 
Synergistic Symptoms supports this tntemal tr^ger with a statement such as: 

"has ChSts" AND *has Fever* AND "has Sweating" implies "Posstbte Malaria." Synergistic Symptoms abo have an 
important use in defining a Syndrome, Le., particular collections of symptoms that occur together so often that, to the 
lay public, they have their own name, such as AIDS. The saipt author can use Synergistic Symptoms to define a 
Syndrome that is knportant to himfher. 

HL Knowledge Capture Details 
The initial task of knowledge capture for a scrqit is identifying the diseases to be induded in the script, 
assigning a priority to each disease, and assigning medical speciafists to develop the porthms of the script for their 
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asstgned diseases. Each medical specialist then generates the appropriate lists needed Jor the ifaeases. This can be 
summarized as follows: 

o define the scope of diseases to be covered; 

o list the diseases and their symptoms; 

o assign rankings, priorities, and weights to diseases and symptoms; 

o design properly worded and weighted questions that will eGcrt the symptoms; 

o format the disease, symptom, and question lists; 

o pre test the lists, using test tools speciafly developed for the purpose; and 

o write the lists as text files, using any ASCII-capable word processor. 
The list-based processing method begins with a set of coordinated lists that captures the elements of diagnosing 
a particular health problem. In this phase, medical experts record their diagnostic skiBs and techniques in the form of 
several lists. To do this, the experts preferably can use any commercially avaitable word processor software that is 
capable of generating an ASCII output fie. 

The ASCII lists for a scr^Jt consist of three types of lists that are nested as follows: 

o one Disease list that identifies aH the diseases the scr^t wSl consider, and ranks them in the order 

they should be considered for diagnosis; 
o one Symptom List for each disease that identif^s the symptoms end assigns a weight to each 

symptom to define the contrdiution it makes to diagnosing the disease; 
o one Question List for each symptom that identifies one or more weighted questions that wiB eBcit the 

symptom from a patient. 

For the purpose of automated medical diagnoses, medical diagnosis data is organized into a hierarchical 
classification that is based on the general concept that diseases have symptoms, and symptoms are elicited from the 
patient by questions. 

A 'disease* b a health condition that requffes treatment or attention such as iDness, ailment, affliction, 
condition, state, problem, obstruction, malfunctton, and so forth. To diagnose a patient with a given complaint, the 
MDATA system begins with a fist of possSila diseases that exhibit the complaint and reduces this to a list of diagnoses, 
based on the patient's answers. 

A "symptom* is any informatbn that the MDATA system has about the patient This includes: 

o patient hlentiftcation (e.g.. name, address, HMO, age, sex); 

o patient history (e.g., prior tosses, parental health information, recent travel to foreign countries); 
o previous accesses to MDATA (e.g., history of patient complaints and progress); 
o physical s^ns (e^. vita! signs) and the results of self- or assisted- phy«cal examination maneuvers; 
° lab and test results; 
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o signs, manifestations, presentations, aspects, and so forth. 
For eacli disease* a ist of symptoms ts prepared. Each symptom is assigned a weight* which represents a Ikelihood that 
the patient has the disease* given the symptom. To sknplify calculations* the mUlA system uses a ruled in threshold 
vahia of 1*000 to declare a disease as diagnosed* although other thresholds may be used. The system abo utibes a 
5 ruled-out threshold to officially declare that the patient does not have the disease. Both the ruled tn threshold and the 
ruled out threshold may be modified by a sensitivity factor set. This permits customized threshold levels* for example* 
for individual patients. The sensitivity factor set will be further discussed herembelow. 

In practice* the weight is a measure of the diagnosing physician s willingness to rule the disease in* given the 
symptom. The weight can also be used as a Conditional Probabifity that Ihe patient has the disease, groen the symptom. 
10 This can be used* if convenient* to apply a Bayesian Probabifity analysis to the symptoms. 

A symptom is elicited by a set of one or more questions* often interlaced whh information and mstructioos on 
how to answer the question. The set of nodes needed to eHcit a symptom is called a 'flow' because it typically tnvohres 
a branching flow of questions* often drawn on a small flowchart* that describes how a dialogue with the patient might 
proceed. 

15 To enter the diagnostic data developed by the medical expert into the MOATA system* the data must be 

organized and formatted. For this purpose* a text file is used and a text file format was developed. The ASCII character 
code is preferably utilized* but any weD defined text-character code* such as EBCDIC* could be used. 
A script consists of several segments or data groups as foQows: 





A. 


DISEASES to be diapnosed in tenns of weighted symptoms; 


20 


B. 


SYMPTOMS to be elicited by flows or implied by other symptoms; 




C. 


IMPLICATIONS that toqicaUy connect symptoms! 




D. 


FLOWS consisting of paths through nodes: 




E. 


PATHS that visit Question nodes: 




F. 


TEXTS that inform andlor advise the patient: 


25 


G. 


QUESTIONS that ask the oatisnt for a response: 




H. 


KEYS that signal a specify response from the patient. 



These segments are part of the following sections of a script 'source** or text file: 
Haadar S action 

The Header section contains data that applies to the entire script* such as script format* and the set of 
30 symptoms comprising the patient*s chief conqilamt. 
DisBssas Sactbn 

The Diseases section Bsts the diseases that can be diagnosed by this script* their symptonts* and the 
symptoms* weight toward a diagnosis. When the script runs during the script development phase* the scrqit 



wo 98/02836 PCT/US97/12025 

■13- 

development tool selects one of the diseases to consider next, and then selects one of that disease's symptoms to be 
considered neat. Miich disease and symptom is selected next depends on the Run Options that are selected by the 
author. The default sequence is the order in which the diseases and their symptoms are fisted m this section. 
DISEASEjmE 

The disease name is a unique label for e disease, used to identify the disease. It is only used internaOy and 
win never be seen by the patient. 

A special code used by the medical professbn to identify the disease. 
FOamLJITLE 

The formal title of the disease. The "formar title is used here because common names for the disease, or 
acronyms, may be added in future formats. 
SYBSPTOSS_MmE 

The name of a symptom that is part of the diagnostic picture or "fingerprint" of the disease. The symptom 
is defined in detail in the Symptoms Section. In the DSQ list context, a "symptom* b a specific, detailed fact about 
the patient that has been assumed, asserted, eGcited, or inferred. The author is free to define any data itemls) as a 
symptom. If it is useful to the author, symptoms may include non-medical facts such as name, rank, and serial number 
of the patient. The intent here is to give the author freedom to express his/her medical experience by defining elementary 
symptoms and grouping them in any convenient way. 

To des^n a symptom, an author may enagine a set of weighted qtmstions that would uniquely assert or deny 
the symptom. If this is no problem, the author defines the symptom ftn the Symptom Section) in terms of its questions 
and answers. If the symptom turns out to be too complex, the author may breatt the symptom into parts, treat each 
part as a symptom, and ask questions about the part. The author may let the patient estabteh each part s^arately. 
and then use the inference mechanism of the Inference Section to estabfish the main symptom^ 
SVE^PTOflSJfEIEKT 

The amount that thb symptom adds to the disease's total score. Technically, the zmm\ can be any number 
from 10,000 to 10,000; reafisticafly it tends to be a small positive integer. As written, the script engine treats 
weights as a way to "score* a disease. When a symptom is estabfehed as being present in the patient, the script engine 
adds the weight of the symptom to the total score of the disease. When the disease score preferably reaches 1.000. 
the script engine rules the disease "in.* 

Simple arithmetic addition of weights may not express the specific way a symptom contriiutes or Indicates* 
the presence of disease. One sohjtmn for the author is to make a first guess of the weights, run the script, observe 
how the disease scores change with each questran and answer, end then go back to *rebalance* the symptoms. 
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A "synergistic symptoms' techmqua may be useful to the euthor in devsioping a strategy for the weights. If 
there are two symptoms A and B that, if present together m a patient, carry more weight than each separately, then 
an artifictat third symptom C can be defined that b bnpSed by both A and B and adds entra weight to the disease. 
Symptom C has no associated questions; it b an mternal "ghost" symptom that can be used only to add or subtract 
5 weights based on the presence or absence of other symptoms. 
Symptoms Section 

The Symptoms section lists and describes all of the syn^toms mentioned in other parts of the script* For each 
symptom, this section identifies the Flow of questions used to elicit the symptom, 

svBffPTOMjfam 

10 The symptom name is a unique label for a symptom, and is used to identify the symptom in other parts of the 

script. The name is only used internally, and will never be seen by the patient. 

The word "flow" is used to describe a specific set of weighted questions, ashed in a specified sequence that 
can be drawn as a flowchart. Thus, a flow represents a smgle group of questions. Since one flow can elicit one of 
15 several symptoms, several symptoms will typically specify the same question flow to be used. Some symptoms (e.g.. 
chief complaint symptoms) have no associated question flow. 
ImEtltcotBons Section 

The ImpBcations section lists the logical inferences among symptoms, so that the script engine knows which 
symptoms imply other symptoms. Each line of the section specifies one or more symptoms that togsthar in^ly another 
20 symptom. That is. each Ene gives the parameters for a logic formula of the form: 

if symptom A and symptom B snd symptom C than symptom D. 
Symptom implications can be chained, so that one anplied syn^otom can imply another symptom, alone or m conjunction 
with others. 

One use of this section could be to estabfish "syndrome" symptoms, so that a specific set of symptoms in a 
25 patsnt would automatically assert a single, collective symptom. This combination symptom could also be used to add . 
(or subtract) extra weight If a specific set of symptoms b present. Le., to allow for the "synergy" of %%mz\ symptoms 
present in the patient at the same ttme. 
mows S^ctkDo 

The Flows Sutton lists aD flows in the script, and defines the sequence of questioru and the symptoms that 
30 can be elicited by the flow. A "flow" is short for "a question flowchart". It can be thought of as a complex question 
that wifl BStabGsh one of several symptoms. Readers famOiar with branch4)ased scripts wffl recognize that the flow can 
serve to contain or caQ an entire branch-based script that returns one of several response codes. 
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It 15 qurte corranon that one needs to ssft a patient sevefal questtons to elicit one specrftc symptom from the 
patient. For example, some prcBminary questions ("Have you ever smoked?") may be needed to set the stage, foSotived 
by quite specific questions {"What is the total time, in years, that you smoked?) to define the patient's symptom 
precise/y. One entffe flow may contam 20 questions about smoking and may elicrt one of several symptoms such as: 
has never smoked; h a casual smoker; has smoked ZO pack years end stiO smokes; and smoked lOiiack years, then quit 
10 years ego. 

Every node in a flowchart is encoded according to the path from node one of the flow taken to get to the node. 
These paths are used to identify what action should be taken at each node. 
Questions Section 

The Questions section defines the details of the questions mentbned by name in the Flows section. The details 
inchide the Preamble, the actual Question, the keys that can be pressed by the patient Ion a telephone keypad), and (for 
graphic interfaces) the button label to be used for each answer. 

The Preamble is the text spoken or displayed to the patient before the question itself is asked. It may continue 
after a previous question, introduce a new subject, define some terms, and inform the patient why a question is about 
to be asked, and how to answer it. Only the name of the text is given here; the actual text is ghren in the Texts 
Sectbn. If there is no preamble for a question, this is indicated with the digit zero as a place hoWer. 
Qi/SSr/OffTEJCT 

The Question text is the actual question. Whereas the preamble may be 10 or 100 fines long, the question is 
typically short, to the point, and calls for a very specific answer that can be indicated by pressing or clicking one of the 
keys. Only the name of the question text is ghren here; the actual text is given in the Texts Section. 

A set of Valid Keys tells the scrqit engine which keys the patient can press or cfck. 

These are key labels, used only in graphic display versions of the script. They tell the engine how to label each 
buttorn for example YES, MO, and NOT SURL 
Teffts Soction 

The Texts section lists the actual text of aD text itwns referenced by name in other sections, such as 
Preambles, Key Labeb. and Questbn Texts. By ghring each text a unique name, and fisting the text in the Texts section, 
the author can use the same text in several places. 

Having aO of the text that is int«ided for the patient bi one place also simplifies eutomated processing of the 
script, such as recording the text for use in a telephone network or formatting the text for display on a screen. A script 
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couM be translated into a foreign language, by replacing its Tents section text with the equivalent text in mother 
langaage. 

DESCOitPTIlOR) OF CCRKDMIEOGE CAPmE QBMWIRSGS 

Referring to Figure 3a. an offff>fine process 280 for generating a DSQ script wtE novv be described. Beginning 
5 at a process 284, medical hnowtedge ts coSected and organized into Est files. The data for the fist fOes b collected for 
one 01 more medical authors 282. Process 284 has two portions. A first portion is typically performed by a scrqit 
coordinator or supervising author for assigning diseases, and a second portion for capturing the disease hnowledge for 
each disease in the scrqit. The portion for capturing the disease ttnowledge is typicaSy performed by a phirafity of 
medical experts in their respective fields. The assigned diseases portion of process 284 wBI be further described in 

10 conjunction with F^ure 4a, end the captured disease knowtedge portion of process 284 wtS ba further descnbed m 
conjunction with Figure 4b. The output of process 284 is electronic text, such as an ASCII fie. This electronic text 
b in the form of DSQ lists such as disease, symptom, and question lists 286. The Appmidix mchides an exemplary script 
for malaria. The script is one representation of a DSQ list. 

A graphical example of tune-based DSQ lists for a script is shown in Figure 3b. An exemplary script 320 for 

15 a time T, and a script 322 for a time T; are shown. Each of these two scripts includes a 6st of diseases 324, a hst 
of symptoms 326, and a list of questions 328. This figure is intended to show the hierarchy of the disease, symptoms 
and question list, and is only exemplary. Note that a disease may refer to symptoms that are defined in other diseases, 
and a symptom may refer to questions that are defined in other symptoms. Thus, symptoms and their associated 
questions can be reused by the various medical authors. 

20 Returning now to Rgure 3a. process 280 moves to state 290, which takes the DSQ lists in electronic text 

format and processes them by use of a script data devetopment tool A saipt compiler 292 works closely with the 
script data development tool to generate an MDS file. The process 280 may utOize the script data development tool and 
the script compiler m an iterative fashion to generate a final MQS file. At state 294, the MOS fOe is written to an tyiOS 
database 300 by an MQS database maneger utffity 296. The MdS file 296 is preferably in a binary format bi an 

25 exemplary representation of the MDS fBe shown in Figure 3a at 296', the A^S preferably includes a header data section, 
a master disease Est section, a master system Ost section, a master fbws sectbn, a master question list section, and 
a master text Bst section. \n another embodimoit, the medical authors may write the scripts m a medical authoring 
language or as nodes and branches, as shown at state 302. Other saipt tools, which may inchide compBers, are shown 
at state 304 to generate an MDS 296. 

30 Referring now to F^ure 4a, the assign diseases process 350 of the collect and organize mec&al knowledge 

process 284 wi now be descrbed. Process 350 wfll typicaSy be paformed by a script coortSnator, ahhough other 
medical professionals utilized by the MDATA system may perform these tasks. Process 350 preferably b not performed 
by a computer but by the script coordinator, who may utilize the computer to assbt in the completion of the following 
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steps. Beginnng at a start state 352, process 350 moves to a state 354, t^herein ths efebf complaint associated with 
the current script is defmed. The chief comptemt mcludes the symptoms that a pattsat might inittaHy provide to the 
system when describing the main problem that they are consulting for. Proceeding to state 356, the script coordinator 
determines a fist of the diseases that are to be diagnosed by the current scrq)t. Thsse diseases should provide a 
diagnosis of the chief complaint, included in the list are the disease name, a dsscrqitor, and an Intmationaf 
Classification of Diseases (ICD-9) code for the disease. Advancing to state 358, the diseases are then ranked by 
probabiOty of occurrence in the generel population that the patient is m. 6.9., country or region of a country. Moving 
to state 3B0, the script coordinator assigns priorities to the diseases based on urgency ami/or seriousness of the disease. 
Based on the assigned priorities, the script engine may be d^ected to check first the diseases that have an urgent or 
serious indication assigned to them. Continuhg at state 362, the script coordinator then partitions or assigns the 
diseases for the current script to one or more medical speciafists for further devetopment Using a computer network, 
such as the Internet, and a DSQ fists database, muhrpte scripts can be developed in paraSel. The disease authors can 
work tn parallel by making questions and instructions available to aS the other authors via the database and the network. 
This capability allows rapid development of the scripts. Process 350 ends at an end state 364. 

Referring now to Figure 4b, the capture disease knowledge portion 3BG of the collect and organize medical 
knowledge process 284 win now be described. Process 380 is also not typicaBy performed by a computer, but is 
performed by a medical speciaDst or eipen who may emptoy the use of a computer to actuaBy capture the disease 
knowledge for a particular disease. The following steps are performed by the disease specialist, as assigned by the script 
coordinator at state 362 in Figure 4a. 

Beginning at a start state 382, process 380 moves to a decision state 384, wherein the medical speciaOst 
determines if the script is best captured as a time-based script. That is, a phirality of scripts at sequential time intervals, 
forming a scr^it family, are to be generated to track the diseases over tene. If it is determined to be a time-based script, 
process 380 moves to state 386, wherein the time interval between scripts in the script family is determined. For 
example, the script author may decide to generate a script for every two hours for a 48-hour tone period. At the 
completbn of determining the time interval for the script family, or If the sa^t is best shown as a single script, process 
380 continues at state 388, wherein the medical specialist identifies a ruRng in threshohf score end a ni!mg-out threshoM 
score for each disease that is assigned to him or her. Moving to state 390, the medical specialist identifies a set of 
relevant symptoms for eacfi disease assigned to them. The symptom fist inctudes the symptom name, a descriptor, and 
at least one weight as described hereinbelow. Contimiing at state 392, the medical specialist identifies any relevant post- 
response relationships and symptoms identified by these relaiionshps. The post-response relattonships may inctode 
simultaneous or synergistic relationships where two or more symptoms occurring together may have more weight toward 
diagnosing a disease than the sum of the weights for the symptoms occurring ^arately. A sequential relationship is 
where the symptoms occur one after the other, which may produce more weight toward diagnosing a disease then the 
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sum of the eseights of the individual symptoms occurring separatety. A variation of the sequenttatr^tionshqi is wherein 
the sequence of the onset or ending of the symptoms produces a different weight than the symptoms do alone. ImpGed 
relationships are wherein the presence of one symptom bnpGes the presence of another symptom. The medical author 
may also define relationships over time for the asserted symptoms and further post-response processed symptoms. The 
5 post response relationships may also involve symptom clarification processing, PQRST array analysis, or a symptom 
severity clarification. The PQRST array is an E\l dffnenstonal array with different attrbutes or aspects of the symptom 
of pain assigned to one dhiension. For erampte, the PQRST array may have twenty-two dimensions. 

Proceeding to state 394, the medical specialist assigns a weight for each disease symptom. For symptoms 
having an associated range, such as a severity of pain or other type of symptom severity, the meifical speciaEst may 

10 assign a range of weights associated with the severity of the symptom. Symptom weights are accumulated into a score 
for each disease having the symptom. Weights can be either positive or negathre, which contr^es to the production 
of a positive or negathfo score. Moving to state 396, for each symptom, the medical specialist defines a flow of 
question nodes to e&cit or determine the symptom. Some symptoms can be determined by a single question, but most 
symptoms may require a number of questions to elicit the symptont For the symptoms requrrmg a plurality of questions, 

15 weights are assigned to the possible responses of the questions at state 397. Thus, this type of symptom may have 
a range of associated weights. Advancmg to state 398, for each question node of the questbn flow, the medical 
specialist writes text objects for the question node so as to provide an introduction or an explanation, instructions, advice 
and the actual questions for the patient. The instructions may define the range of vahjes that are requested (an answer 
set) or other ways of formatting the expected responses. The introductions and explanations are to help the patient 

20 understand what the question is about, why the question b bemg astced, and sets the stage for the possSite responses. 

For each symptom the author will compose a question flow that is used to elicit the symptom. The question 
flow that the author uses may be another physician's question flow. For example, let's say the symptom is depressmn. 
To estabBsh the symptom of depression, one doctor may astc, "Are you depressed?**. This m^ht be called 
depression_question_1. Let's say that the author does not lihe it. It is too terse and really does not capture what is 

25 wanted. So the author tooEcs further in the questbn database. The author may find and look at 
depressbn_question_fbw_2. This question flow is much more elaborate. In this flow, to answer the questkin, "Are 
you depressed?", this doctor has davbed a 10-point bst of questions. The sub-questions may even be other questbns 
in the database. In this question f tow, the patbnt is asked ten questions. Each question is weighted differently end, 
aft» answering all of the questions, the score is totaBed. and if It reaches a threshold defined by the question's author, 

30 then this physician will say that the patient has the symptom of depression. 

In another exampte, say an author wants to ask a question about nausea for migraine. The author exammes 
the question bank. The author may find fifty ififferent questions on nausea. One question says, 'Are you nau^ated?*. 
This question is not acceptable to the migraine author. Another author has a question flow that contains ten weighted 
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sub-questions. If their score reaches lhat author's pre-defined threshold, that doctor caOs his patient nauseated. The 
migraine author fihes it almost as is. but wants to change one of the weights of one of the waQhted sub-quastions. 
In thb situation, the migraine author saves the new question with the revised weight as nausea_question n+1. Now 
when the migraine author uses the new version or another version of nausea, it will of coarse be weighted differently 
in defining different diseases. 

If questions of different weights are not allowed in the question flows, then afl the questions wSl be. by 
definition, weighted the same. But when a disease author, irymg to see if, say. abdominal tendemess is present, wiU 
ask the patient to do a series of maneuvers such as: -fTease cough. Does that make your abdomen hurt?" If the 
patient says "yes", the disease author may then ask the patient to press on his abdomen and ask if that hurts. The 
disease author usually asks or requests the patient to perform many such maneuvers to establish the -symptom" of 
abdominal tenderness. However, these questions are not all of equal importance in defining abdominal tenderness. If 
a patient hurts when his abdomen b pushed, that is much more significant than the couglmig maneuver. 

After the question nodes have been completed at state 398, a medical speciaSsi determines at a decision state 
400 it another time interval for a time-based script is required. If another interval is not required or if the present scrqit 
is not a time-based script, process 380 ends at a return state 402. However, if another interval is requbed in a time- 
based script, process 380 moves bach to 388 to rerun the set of steps 388 to 400 for another time interval in the script 
famSy. 

N. Script Generation Details 
biternal to the MDATA system, Gsl-based medical diagnosis data is stored as scripts. These ffles are the 
diagnostic interface between the human doctor and the patient being interviewed. At run lime, a MDS fib 'runs* by 
drning a script engine, which is a generic program that toads MOS ffles and runs the script based on the data and 
instructions encoded in the fBe. Diagnostic data are stored in the form of disease, symptom, question, and text node 
fists. 

The contents of a list-oriented MOS lite mirrors the contents of the ASCII fist file. The major ififference 
between them b that the text file data b stored as segments of text Gnes of character stroigs, whereas the MDS file 
data is packed mto Bsts of binary integers. A second dHference a that the MDS fBe data is arranged and cross- 
referenced to support on-Gne access to the data. 

The MDS f Be b preferably formatted as one very large array of 32-bit binary integers. Thb targe array b then 
aflocated into blocks of varying length that contan data. Since the location of a block in the fSe b itself a numbw, it 
can be used as a data hem that connects one bioch to another bkiek. Physically, these blocbs are faidependent of any 
programming language or operating system and can be transported to any computer hardware that is capabia of storing 
ffles of 32-bit numbers. Logically, these blocks can be nested and connected in art)iuary ways to form data suuctures 
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such as fintted fists, staclts, queues, trees, and networks. The MDS file is formatted as several segment blocks caned 
'master fists'* as foSows: 

o Header Data, 

^ Master Disease list 

o Master Row Lbt, 

o Master Qt»stion List, 

° Master Symptom List, 

0 Master Test List. 

To prepare a MDS file, the ASCII fist fSe is read and converted into a MDS file by the script compiler. This 
process consists of reading the ASCII text fife line-by linB, compi&ng the appropriate segment of the corresponding MDS 
output f ae, and generating cross-reference fists to speed searches. Since some symbols may be used before they are 
defined, the conversion program must make two passes through the file. During the first pass, all lines are read in, 
converted into MDS Ite blocks, and their symbols are saved in a table. During the second pass, symbols are replaced 
by their actual block addresses. Of course, other methods of compilation may be used. 

The conversion program can, of course, perform any number of quafity and consistency checks, such as 
detecting invalid formats, missmg segments, duplicate symbols, unused symbols, typographical errors and so on. Coupled 
with a simple text editor, the conversion program can let the script author make corrections in the ASCII list file and 
then rerun the conversion program again until it accepts the file. This editing cycle serves to catch fundamental source 
errors and typographical errors early. 

After the script is compiled, the script author tests the script to determine whether it functions as bitended. 
If not, the script euthor may, for eEample, adjust symptom/question weights, fme-tune words and phrases for the question 
nodes, and fix any (ogtcal and medical errors. The saipt author will then recompile and rerun the script untB it runs as 
intended. 

Referring to Figure 5, the script compBer 292 wifl now be descrfeed. The DSQ fists that are m an electronic 
text format, such as ASCII, are coDected by use of the script data devetepmant tool and then processed by the scrqit 
compiler 292. B^inning at a start state 420, the script compBer processes the source script for compteteness, 
consistency and uniformity. Syntax errors are tdentif^d at this state. After any problem areas are corrected, the 
cbmpOer proceeds to state 424 »id converts the script from the source format to the stored f3e format, which is a 
bmary format. Continuing at state 426, the script compiler 292 augments the script for access to the various MDATA 
databases, shown in Figure 2, and the MDATA infrastructure or support system. The script compiler completes at a 
return state 428. 

V. Scriot Execution DetaBs 

Overview 
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When a patient accesses the MDATA system 100 for a diagnosis, the system manages the initial contact with 
the patient, identifies the patient, decides which service the patient needs, selects the correct MDS file, and starts up 
the script engine. The script engine loads the MDS file and begins to obey its coded directions, one by one. The effect 
of obeying the coded directions is an interview whh the patent. At the end of the interview, the script directs the 
engme to perform appropriate terminal actions (updating databases, closing files, logging the session) and ultimately 
returns computer control to the MO ATA system 100. 

Using an MDS file to drhfe a script engine to conduct an on line intervww is described hereinbelow. The 
supporting operations required to access database files, output infomiation to the patient, btput the patient's responses, 
and print reports, is performed by the underfymg operating system on which the script engine is running. 

The run time mode of the List-Based Processing method generates a MDS file that is list-oriented. That means 
that, at each step, the disease, symptom, and question fists must be searched to determine the nent question or action 
of the script. The script engine has to do more work using the fist-based method than a branch-based method. 

The MDS fie is, in essence, a medical encyclopedia of human diseases, stored in top-down order from a high- 
level list of diseases down to a single question that elicits one aspect of a symptom of one disease. To run such a data 
structure as a script requires that the structure be "inverted," Le., presented as a sequential question stream to the 
patient. To do this m the run-time mode, the script engine first searches the master disease list of the MDS file to 
select the next dbease to be considered. Then the engine searches the list of symptoms of the selected disease to select 
the next syn^tom to ask about. Then the engine searches the question set for the selected symptom to select the next 
question to be asked. The engine poses the question to the patient, obtams the answer, updates the various weighted 
lists, and repeats the process until it reaches a diagnosis or runs out of diseases. The overaO effect is to generate a 
diagnostic conversation between the script and the patient that conchides with a diagnosis. 

As the script runs, the script maintains the patient's symptom set as a temporary dynamic Rst caDed a "temp" 
list. Every new symptom is recorded in this set, and is used to update the Bst of diseases being considered. The 
patient's responses thus huM a heahh profile that is used to select the next disease and symptom and question. The 
profile serves a number of uses: 

° it is used to update aO diseases being considered, to aid in selecting the next disease; 

° it can be used to make statistical comparisons of cases; 

o it aDows the MDATA system to dynamically alter the question stream based on a specific patient's 
health state; 

o it allows the MDATA system to interrupt a script and to contmue it later, by storing the profSe and 

rebadtng it at a later tene to continue the script 
When the script engine begins, it is given an on-fine patient end a script fte., a MDS ffle). The engine opens 
the MDS fae to establish access to the coded lists of diseases, symptoms, and questions, tt also opens the patient 
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record to obtain the patient's medical history and the results of past sessions, if any, with the patient. From 
hereinf orward, the MDS fib drives the intervEew by directino the engine to a next interview step. At the end of the 
interview, the script dkects the engine to perform appropriate terminal actions (updating databases, clos'mg files, logging 
the session) and ultsnately returns computer control to the MDATA system. 

The aspect of interest for this explanation of list-Based Processing is the algorithm used to question the patient 
and to build up a set of symptoms toward a diagnosis. This algorithm consists of a main loop that analyzes and updates 
a set of patient symptoms until it reaches some ccnditbn that temtinates the loop. The main loop inchjdes the following 
general steps: 

o analyze the patient's set of symptoms, 

o select the disease to be considered next, 
select the symptom to he considered neat, 

o select the question to be presented next, 

o present the question to the patient and process the response, 

° update the symptom set based on the response, 

^ perform post-response processing of the symptom set, 

o loop to anelyze the patient's set of symptoms. 
This main loop conttnues until the script terminates with some exit action such as forming a diagnosis, giving treatment 
advice, or forwardmg the patient to another script. 
Dascription of ihe Seroptt Eueeoi^em fiPretftrifiiss 

Referring now to Figure 6a, a general configuration of the MDATA system for operating the diagnostic script 
engine 190 win now be described. The diagnostic script engine tSO interfaces with a MDATA support systwn 440 so 
as to get access to a plurafty of databases 442 of the MDATA system and to have input and output capabiEties with 
the various entities in the medical community. The MDATA support system 440 includes the processes shown in Figure 
2, including the login process 210, the registration process 212, and the diagnostic process 220. Also inchided m the 
MDATA support system 440 are processes for performing input end output to and from the physician 444, the patnot 
1 14, and health organizations 446, such as a health maintenance organization mO). The ftflOATA support system 440 
uiaizes the communication networtt 102, previously shown m Figures la and lb. The databases 442 shown in Figure 
6a inchide the databases previoushr shown in Figure 2 and also inchide other databases such as for human tfiseases, 
drugs and drug interactions, human anatomy, a regulatory ratchet table, and a geographic distribution of frequency of 
diseases. The regulatory ratchet table is a table of regulatory and legal *-rules" that let the systwn hnow bow much 
information can be revealed to a patient. 

Rof ening now to Figure 6b, the structures and inputs and outputs utffized durmg the operation of the ifiagnostic 
script engine wiQ now be described. Based on input from user 460, records from the patient medical history database 
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254 and other taformation available from the central MOATA databases 442, a (WDS 296 is setscted from the MDS 
database 300. Altemathfely. if the diagnDstfc script engine 190 is ran on a patient's personal computer, local user data 
storage 184 may be accessed in place of the MDATA databases stored at a central locatton. However, it b more 
practical to beep the patient medical history at a central database for several reasons: safety of the records, health care 
providers anywhere in the world have access as necessary for analysis, matching a diagnosis to any new treatments so 
that a patient can be quickly notified by the system, and so forth. 

The ms 29B is made available for the diagnostic script engine 190, which perfomis the patient interview. 
The script engine 190 may write information receh^ed during the patient interview to either the central patient medical 
history database 254 or to the local user data storage 184. At the conclusion of the current script, or if additranal 
scr^its are run, medical diagnosis or advice 462 may be generated. This diagnosis or advice b preferably reported to 
the physician 464, output to the user 486 and stored in the central (WDATA databases or the local user data storage 
184. Other reports 468 may be generated as necessary. As wi« be descr&ed later, th^e are situations where the 
diagnosis may not be reported directly to the user, but may be sent instead to the physician for further reporting to the 
user at a later time. 

Referring to Figure 7, a general top level process 480 for a user in a session writh the MDATA system 100 wiD 
now be described. Process 480 begins at a start stale 481 and moves to state 482 to identify an emergency situation. 
A set of initial "hard-coded" saeening questions are utiEied to identify the emergency situation. If an emergency 
situation rs identified, appropriate advice, such as calling 911, is provided to the user. State 482 and subsequent states 
484, 486 and 488 are substantiatty described in AppQcant's copending application emitted "COMPlfTERIZED MEDICAL 
DIAGNOSTIC AWD TREATilflEWT ADVICE SYSTEM." U.S. Serial Wo. 08/176,041. If process 480 determines that there 
is no emergency situation, the process continues at state 484 and securely identifies the user. As described m 
AppBcant's copem&ig application, the user may be the patient or an assistant for the patient. Passwords, identification 
numbers, voice prints or other types of identification methods may be utilized. H the patient has togged in properly, 
process 480 continues at a state 486 to perform any necessary administrative tasks. Proceeding to state 488, process 
480 access the MDATA medical databases (Figure 2) and the system fSes end software. Proceeding to process 490, 
an on-fine interview with the user is conducted. The on-fine interview preferably is pwf ormed by the diagnostic script 
engine process 490. However, other ways of performing the on-line interview may be utifeed, such as running a program 
or executing a script The user process 480 completes at an end state 492. 

Referring now to Figure 8a, the diagnostic script engine process 490 wfll be described. Beginning at a start 
state 492, the script ermine process 490 proceeds to stale 494 to perform a script router function. The script router 
selects an appropriate DSQ scrqjt based on input parameters such as: a patant's chief complaint symptoms, the time 
since the symptoms started, the patient's past medical history, results from any other scripts, or the results from the 
current script f am3y from a prior time. Identification of the paifent's chief complaint is algorithmic. The chief complamts 
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can be categorired into the f oBowtng classifications: an anatomic system involved, a cause of the patient's profaian^ e.0., 
trauma or infection, an alphabetic list of chief complaints, an ICO 9 number for their complaint, or a MDATA cat^g 
number of their chief complaint. After the appropriate OSQ scr^it has bean setected, process 490 continues at state 
496 to retrieve the satacted scr^t from the scr^t database 300 (F^ure 6b). At this tana, tha diagnostic script engine 
5 process 490 mvotces a DSQ fist script engine 500 to utifize the DSO lists in performing the interview with the patont. 
The DSQ list script engine 500 will be further descr&ed in coniunctton vifith Figures 9 and 11. 

The diagnostic script eng'me process 490 post-processes the results of the DSO saqit engine at state 501 
Various types of processing are performed at state 502, as esemplifed by states 506 through 526 described here'mbelow. 
One action that may be performed at state 502 includes determining a degree of certainty for diseases in the rutedtn 

10 disease list end in the ruiad-oiit disease Dst. The degree of certainty for some or aD tha diagnoses in the rutsd-in end 
ruled-out dbease Hsts may be reported to the patient and/or physician. The diagnoses from the ruled*in and ruled out 
disease lists and the associated degrees of certainty are comp3ed into a differential diagnosis list. Various ways of 
determining the degree of certainty for a diagnosis tnchide, for example, a degree of certainty looEt-up table or a 
sensithfity factor set. Sensithrtty factors were previously described in AppHcant's issued patent, II.S. Patent No. 

15 5^594,638, entitled "COMPUTERIZED mumi DIAGNOSTIC SYSTEM INCLUDING fiE-ENTEfl FUNCTION AND 
SENSITIVITY FACTORS." The nejit ection performed by process 490 is dependent on the result type as determmed at 
a decision state 504. Various exemplary result types wilt now be described. At state 506, the diagnostic script engeie 
process 490 refers the patient to another script, which is selected at state 484, as previously described. At state 508, 
process 490 generates appropriate medical diagnosis or advice. Moving to function 510, the advice is distributed to the 

20 appropriate party. Function 510 w3l be further described in conjunction with Figure 6b. After the advice is distrOtuted, 
process 490 ends at an end state 512. 

At state 514, process 490 performs a special meta analysis. The diagnostic script engine studies how a 
specific symptom changes or grows over time m a given disease. At state 516, process 490 stores the results 
accumulated during the script mto the patient's records. At state 51 B, process 490 forwards the patient to access a 

25 roeifical information library that is part of the BiiDATA system 100. At state 520, process 490 schedules a later 
continuation of a script that was adjourned temporarily. TypicaOy, this occurs when a patient is not able to complete 
the entire script during a session, to a situatbn where no disease has reached a rule-in threshold, the diagnostic saipt 
engbie has the capabifity of providing a Bst of diseases that have the most weight in decreasing tevels of probabity to 
the patient, h such a situation, at state 522, the process 490 could schedule e re-enter session to aOow a length of 

30 time to pass and sra if a diagnosis could be reached at a later time. The re-enter feature is described in Ai^riicant's 
copending applkation entitled "COmiTEfllZEO MEDICAL DIAGNOSTIC AND TREATMENT ADVICE SYSTEM." At state 
524, process 490 requests the patcant to have tests performed and to consuh tha system again. These tests may 
include self-exam maneuvers, imaging modaSty tests (258, Figure 2) or laboratory tests (260, Figure 2). At state 526, 
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process 490 forwards any urgent results to a health care provider for immediate action. Process 490 ends at the end 
state 512. 

Referring to F^ure 8b, the distribute diagnosis or advice function 510 will now be descried. Beginning at a 
start state 511. function 510 proceeds to state 512 wherein the results of the various fots are coHated due to one or 
more diseases or diagnoses reaching threshold. Proceeding to state 515. function 510 checks the treatment table for 
the appropriate and current treatment for the diagnoses made by the system. ProceadinB state 517. function 510 
determines who should be the rec^isnt of the diagnosis or advice. This is partiaBy accomplished by consulting a 
regubtory ratchet table 519. The regulatory ratchet table determines the type of mformation that can be toU to the 
patient depending on various factors, such as what country the patient Ihfes m. As a result of consulting the regulatory 
ratchet table 519, advice or a diagnosis is communicated to the patient 114. a physician 444, a managed care 
organization 446 or other entity 521 that legally may have access or has a need to ttnow the medical information. There 
is much information that could be shared with the patient and should be shared with the patient's physician. For 
example, what is ruled in and what is ruled out. and what is the patient's specific differential diagnosis? That is. after 
the patient answers aD of the questions, the scores for aB of the different diseases can be ranhed. This is very helpful 
to the physician. The regulatory ratchet table 519 utibes informatbn available in the patient's record, such as the 
patient's rip code or tetephone area code to identify their location. 

Referring to Figure 9. the DSQ script engine process 500 wiD now be described. Beginning at a start state 
530. the process 500 proceeds to state 532 to access the selected DSQ Dst file passed to it by the diagnostic script 
engine. Proceeding to state 534, process 500 initializes the temp lists utifized by the script engine. Referring temporarily 
to Figure 10, process 500 initiaSzes the symptom temp list 552 to be cleared and initializes the disease temp fist 550 
to have all of the diseases of the master disease Ibt 324. At this point, process 500 selects one of the dbeases to 
be processed and then selects a symptom to be asserted m the disease. To determine the presence or absence of the 
symptom in the patient, process 500 continues at state 538 to select the first question of the symptom to be asked 
of the patient. At state 538, process 500 asks the question of the patient. (Moving to state 540. process 500 receives 
the patient's response and checks for correctness of their response according to the asked question. The patient's 
response is used then to update the DSQ temp fists at state 542. 

Proceeding to a decision state 544, process 500 detemnnes if a diagnosis or a terminus of the script has been 
reached. If it has not, process 500 proceeds to state 546 to select either the next question in the current symptom, 
or, if all the questbns for the current symptom have been asked, to proceed to the neat symptom for the current disease. 
If aQ the questions in the current disease have been asked, process SW) moves to the next disease and asks the 
questions necessary for that disease. Process 500 loops at states 538 through 546 untB the end of the $crq)t is 
reached, a (fiagnosis is achieved, the user requests the script to be adjourned, or the script engine detenranes that the 
script should be terminated. When the diagnosis or terminus has been reached, process 500 either returns the diagnosis 
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at state 541, refers the patient to a ififferent script at state 543, adjourns the current script at state 545, or terminates 
the current script at state 547. Process 500 completes at a return state 548. 

Referring now to figure 10, b portion of the Bsts utilized during run tmie operstron of the DSQ list script engine 
500 will be described. Based on user input 460 and the time since the symptoms have begun, the script router 494 
5 (Figure 8a) of the diagnostic script engine 490 identifies a script to be passed to the DSQ list script engine 500. The 
records of the current patient from the paUsnt medical history 254 are also used by the script router 494. Using the 
medical diagnostic script received from the script router, the DSQ list scr^it engine 500 accesses the master disease list 
324. The diseases in the master disease list are copied to a disease temp Bst 550. At the appropriate time during 
operation of the DSQ list script engine 500, symptoms from the master symptom fist 326 of the current dbease are 

10 selectively copied to the symptom temp list 552, as will be described in conjunction with Figure 12. As symptoms are 
asserted during the patient mterview, symptom weights and/or questkm weights for the symptoms w^l be added to the 
score for the current disease in the disease temp list 550. When a score for a particular disease reaches a ruled-m 
threshold, the disease is moved to the ruled-in disease list 554. Alternatively, if the score for the current disease reaches 
the ruled-out disease threshold, the disease is moved to the ruted out disease list 556. Asserted symptoms, ruled-in 

15 diseases, rufad out diseases, and diseases neither ruled in nor ruted-out may aD be stored in the patient medical history 
254. At the completion of a script or at a terminus or checltpoint during the script, diseases left in the disease temp 
fist 550 may also be written to the patient medical history 254. Altemathrely, the patient symptom and disease 
information may be written to the local user data storage 184 (F^ure 6b) instead of the central patient medical history 
254. 

20 Referring now to Figure 1 1, the operation of the DSQ list script engine 500 wtO be described. This description 

wiQ provkle more detail than the overview of the script engine process provided in conjunction with Figure 9. Beginning 
at a start state 580, the script engine process 500 proceeds to state 582, wherein the disease torqi Bst 550 is tnrtiaEzed 
from the scrq»t master disease list 324 (Figure 10). Moving to state 584, the script engine process accesses patient 
data from current and/or previous patient sessions. The script engine process 500 utizes the MDATA support system 

25 440 (Figure 6a) and the databases 442 to get the patient data and any other data necessary. Attematively, the patient 
data may be retrieved from the local user data storage 184 (Figure 6b). 

Advancing to state 586, the script engine process 500 selects the disease to be considered. Various methods 
may be utffized m selecting the order of the diseases to be considered. For eaampfe, the most urgent diseases may be 
considered first, followed by the serious diseases and then the contmon diseases. Altemathrdy, or m conjunction with 

30 the urgent/serious model, the first diseases to be consklered may be the most prevalent in the population that the pattant 
is in. The script engine process may utilize the telephone number, postal z^ code, or other sources of location 
information from the patient's history to identify the population group or location that the patient is in. An alternative 
for selecting the disease order once the process has started is to use the doease with the highest total of symptom 
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weights, Le., the disBSse which is nearest to being diagnosed. Preferably, the script coordinator arranges the diseases 
for the current script in the order they are to be considered. After the current disease to be considered is determined, 
the script engine process 500 proceeds to the ''select symptom to be considered" process 588. Process 588 determines 
the symptoms to be conshiered for the current disease and will be further descrbed in conjunction with Figure 12. 

Script engine process 500 chectts to see if a selected symptom null flag, which may be set during process 588, 
is asserted at decision state 590. If the selected symptom flag is null for the current disease, process 500 advances 
to a decision state 616 to determine H there ere more diseases to consider. However, if the selected symptom flag is 
not null, script engine process 500 proceeds to state 592 to select the question flow to be presented to the patent. 
Associated with each symptom is a question logic flow that can eficit the symptom. A (ogic flow can be thought of as 
a 'complex question,*" Le., a question that consists of several questions and can produce one of several answers. 
Preferably, the question flow which contains, j.B., can generate as a response, the symptom which currently has the 
highest chance of ruling in the disease under consideration should be selected. Advancing to state 594, script engme 
process 500 then executes the current flow node. Proceeding to state 596, script engine process 500 presents the 
questbn part of the flow node to the user. Every question preferably consists of a set of information text, instruction 
text, and a question. To present the question, the script first outputs the information text to the patient, then the 
eistruction text, and finally the question text. The question text indicates to the patient that a response is expected at 
the present time. 

Continuing at a handle response process 598, the script engine processes the response from the user. Process 
598 wPI be further described in conjunction with Figure 13. The flow node preferably is one of three types: symptom, 
question, or program. Script engine process 500 determines the fbw node type at a decision state 600. If the node 
type is question or program, script engine process 500 moves to state 594 (question bop Q) to execute the nest flow 
node. However, if the flow node type Is of the symptom type, process 500 proceeds to state 602 to update the 
symptom temp list 552 (F^ure 10), based on the recehred response from the patent. Based on the response, a weight 
is assigned for the current symptom. Alternatively, if the current symptom utilizes multiple questions, some of which 
have associated weights, the weight (if present) for the current question is accumulated for the current symptom. 

When the DSQ script has obtained a symptom, it updates an (fiseases that have the symptom. That b, a smgia 
answer from the patient can change the symptom weighing of aO diseases being considered. This "promotes" one or 
more diseases to being cbser to the diagnostic thresholds. 

Proceeding to a function 604, the script engine process 500 performs post-response processing to further update 
the symptom t^p Ost 552. Examples of post-response processing tnchide if-then relationships, smurftaneous relatbnships, 
sequencing relatbn^ips and otha simSar types of relationships. For example, if a symptom severity vahie is 9, then 
a weight of 75 might be added to the diagnosis of biliary coDc, and a weight of 50 might be subtracted from the 
diagnosis of appendicitis. Other post-response relationshqis were previously discussed in conjunction with Figure 4b 
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(capture disease ttnowtedgB). After the post-response processing has been completedr ^ script enotne process 500 
proceeds to the update disease lists process 606. At process 606. the script engino updates the scores in the disease 
temp fists based on the updated symptom temp list 552 and eliminates ruled m or ruted-oatt diseases. The update disease 
list process 606 wSI be further described in conjunction with Figure 14. 

5 At the completion of process 606, some diseases may be ruled in or ruted out, thereby reducing the length of 

the disease temp fist 550 (Figure tO). Hoi^ever, if either the ruled in threshold or the rubd-out threshold has not been 
reached, the disease is not removed from the disease temp Kst. Thus, at state 608, sn updated disease temp Hst and 
an updated symptom temp yst are teft for the next iteration of checking symptoms for diseases. Movmq to a decision 
state 610, the script engine process 500 determmes if there are more symptoms in the symptom temp list 552 for the 

10 current disease, if so, the script engine process 500 selects the symptom with the largest weight, based on absohtte 
value, associated with it at state 612 and then proceeds to state 592 (symptom loop S| to select the question flow for 
that new symptom. However, if there are no additional symptoms in the symptom tranp hst 552, as determined at 
decision state 610, the script engine process 500 proceeds to state 614 to delete the current disease from the disease 
temp list 550. 

15 Proceeding to the decbion state 616, the script engine process 500 determines If the disease temp list 550 

for the current script is empty. If it is not, the script engine process 500 moves to state 586 (dbease loop 0) to 
consider the nest disease in the script. If the disease temp list 550 for the current script is empty, the script engine 
process 500 proceeds to a decision state 618 to determine the type of result of the script. At state 620, one of the 
possible results is that one or mora diseases have been ruled in or have been ruled out. At state 622, another type of 

20 result is that the script engine has determined to reference another script or enother service. The script engine process 
500 completes at a return state 624 and returns to the diagnostic process 490 (Figure 8a}. 

Referring to Figure 12, the select symptom process 588, referenced in Figure 11, will now be descr3>ed. 
Beginning at a start state 640, the select symptom process 588 proceeds to state 642 to dear the symptom temp Est 
552 (Figure 101 Proceeding to state 644, the select symptom process 588 accesses the current disease in the script 

25 master disease fist 324 (Figure 10). Advancing to state 646. process 588 identifies the nent symptom of the current 
disease. Continubig at a decision state 648. process 588 determmes if the symptom's question fbw has previously been 
executed for thb patent. For esample, the symptom may have been determined in another disease or even in anothn 
script for this patient. If the question flow has not been previously executed, process 588 proceeds to state 650 and 
adds the symptom to the symptom temp bst. After adding the symptom to the symptom temp 6st, or if the synqitom's 

30 question flow has beoi previously OKOCuted, process 588 moves to a decis'ron state 652. At decision state 652. process 
588 determines if there are more symptoms for the current disease. If so, process 588 moves back to state 646 to 
identify the next symptom of the current disease. 
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If there are no more symptoms for the current disease, as determined at state 652, process 58B continues at 
a dectsbn state 654 to determbie if the symptom temp fist 552 is empty. If it is, select symptom process 588 moves 
to state 656 to delete the current disease from the disease temp list 550. This would happen, for example, if aO the 
symptoms for the disease had been previously considered at an earlier time in the or another script. In this situation, 
the select symptom process 588 returns at state 658 wi» a nuB symptom flag. Returning to decision state 654, if the 
select symptom process 588 determines that the symptom twnp Est is not empty, execution contmues at state 660 
wherein the symptom temp fist is sorted by the absolute value of the weight. Proceeding to state 662, process 588 
selects the symptom with the largest absolute vahw of the weight. The select symptom process 588 returns at state 
664 to process 500 (Figure Tt) with the selected symptom. 

Referring to Figure 13, the handle response process 598, referenced in Figure 11, wifl nuw be described. 
Beginning at a start state 690. process 598 proceeds to state 692 to check the vaOdity of a user response. Proceeding 
to a decision state 694. process 598 determines if the response is valid. If the response is not valid, process 598 
proceeds to state 696 to repeat the output of the question text to the user and then moves back to state 692 to check 
the validity of the user response. A check for a time-out situation occurs during the handle response process 598. The 
timeout is evaluated to see if it could mean a possible loss of consciousness or a change m mental status. If so. a 
mental status subroutine could be invoked or emergency medical personnel may be called, for example. 

If the response is determined to be vaM at the decision state 694, process 598 proceeds to a decision state 
698 to determine the type of node currently being processed by the DSQ script engine 500. If the node type is a 
symptom node, process 598 proceeds to state 700 to select the symptom vahie associated with the current flow node. 
A symptom node returns the symptom as the answer to the complex question. The symptom vahie is then returned at 
state 702 to the symptom script engine process 500 {Figure 11). If the node type is a question node, process 598 
proceeds to state 704 to comrert the response to a path digit. Advancing to state 706, process 598 appends the path 
digit to the current flow node path name. State 704 and 706 are used to identify the next question node to be 
executed. Returning to decision state 698. if the node type b ttetermined to be a program node, process 598 proceeds 
to state 710. At state 710, process 598 executes the program indicated by the current node and gets a return digit. 
Continumg at state 712, process 598 appends the return digit to the current flow node path name. State 710 and 712 
are used to identify the next question node to be executed. The program executed at state 710 may be a sub script 
or other function or subroutine needed to elkit additional medical information from the patient. At the completton of 
either state 706 or 712. process 598 returns at return state 708 to the OSQ script engine process 500 (Rgure 1 1). 

Referring to Figure 14, the update disease lists process 606, referred to in Figure 11, will now be described. 
Begmning at a start state 730, process 606 procrads to state 732 to access the disease temp fet 550 (figure 10). 
Continuing at a decision state 734, process 606 determines if there are more diseases in the disease temp list 550. 
If not, process 606 returns at a return state 736 to the OSQ script engine process 500 (Rgure 1 U However, if there 
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are more diseases in the temp Dst, process 606 proceeds to state 738 to access the next disease in the dbease temp 
list 550. Proceeding to a decision state 740, process 606 determines if the current disease contains the symptom pjst 
answered by the patient or any of its post-response processed symptoms, such as determined at function 604 {Rgure 
11). If so, process 606 moves to state 742 and adds the weight of the symptom just answered or the post*response 
process symptom to the score of the current disease, f^oceeding to a decision state 744, process 606 determines if 
there are additional symptoms having weights that need to be added to the current disease score. This typically would 
happen if there are multiple post-response process symptoms. If so, process 606 moves back to state 742 to add the 
weight of these additional symptoms to the disease score. If there are no more symptoms that need to be processed, 
as determined at state 744, process 606 proceeds to a decision state 746. 

At decision state 746, process 606 determines if the disease score has reached or passed the ruled-in threshold. 
The ruled-in threshold preferably has a value of 1,000, but other ruled in threshold scores could be utilized. If so, process 
606 proceeds to state 748 to add the current disease to the ruled-in disease list 554 (Figure 10). E^ovmg to state 750, 
process 606 deletes the current disease from the disease temp list 550 {Figure 10) and then moves back to decision 
state 734 to determine if there are more diseases in the temp fist 550. 

Returning to decision state 746, if the score has been detemuned to not reach or pass the ruted-in threshold, 
process 606 proceeds to a decision state 752. At decision state 752, process 606 determines if the disease score has 
passed or has reached the ruled-out threshold. If so, process 606 moves to state 754 to add the current disease to the 
ruled-out disease list 556 (Rgure 101 Advancing to state 750, process 606 deletes the disease from the disease temp 
list 550 and moves back to decision state 734 to check for additional diseases in the disease temp ist 550. 

Returning to decision state 752. if the disease score is not tess than or equal to the ruled-out threshold, process 
606 moves back to decision state 734 to check for additional diseases in the tmp 6st 550. Returning to decision state 
740, if the current disease does not contain the symptom just answered or any of its post-response processed symptoms, 
process 606 moves back to decbton state 734 to check ior additional diseases m the temp Est 550. 

The use of the ruted in threshoU and the ruled out threshold has c^tain implications as follows: 

the weight of a symptom can be given as a posithre or negative number; 

two running scores are Itept for each dbease: one positive and one negative; 

positive we^hts ere added to the poative score and negative weights to the negative score; 

weights are not subtracted; 

two threshoU are used, a positive one (e.g. 1000 or 10000) to ride diseases in and a negative one {e.g. 1000 
or 10000 to rule diseases out; 

when the positive score reaches or esceeds the positive threshold, the di^ase is ruled-in; 
when the negathfe score reaches or exceeds the negative threshohf, the disease b rutad-out; 
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if a disease reaches neither threshold by the end of the script, it is left in an "undecided" fist of diseases, 
which can be stored in the patient medical history. 

Referring to Figure 15, an alternative embodiment for genvating medical advice or a diagnosis using branch- 
based scrqits will now be described. Beginning at a start state 782. the branch based script process 780 proceeds to 
state 784 to open a branch-based medical diagnostic script file. Proceeding to state 786, process 760 sets up the 
patient data from either current and/or previous sessions with the patient. Script process 780 proceeds to state 788 
and starts at a first question m the saipt. Advancing to state 790, script process 780 presents the current question 
to the user. Continumg at state 792, script process 760 waits for a vafid user response. Momg to state 794. script 
process 780 records the user response. At state 796, script process 780 goes to the node corresponding with the user 
response. Continuing at a decision state 798, script process 780 determines if the next node is an esit node. If not. 
process 780 continues at state 790 and presents the next question to the user. The script process 780 loops on states 
790 through 798 according to the s«)uencB of the predetermined script nodes until an exit node is reached. When the 
exit node is reached, script process 780 moves to a decision state 800 to determine the type of result of the script. 
The branch-based script 780 may return a diagnosis at a return state 802, advice at a return state 804, or a reference 
to another script at a return state 806, 

VI. Advantanes of List-Based Processina 
The List-Based Processing system provides advantages of speed, precision and completeness over other methods 
of medical diagnoses. Specifically, the List-Based Processing approach: 

organizes medical ttnowledge into fists that others can process; 
_ presents diagnosis in a way that can be checked for correctness and completeness; 

generates better scripts than humans can write using branch-based scripts; 

simplifies updating scrqits as medical knowledge changes; 

aDows testing by automated means; 

can be used as a callable function from branch-based scripts; 
_ is computer platform-, medium-, and language-independent; 

albws scripts to be more easdy translated into other human languages; 

reflects the way doctors actually diagnose. 
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APPEWDtX 

EXEgflPLARY DSD IBST-3ASE9 SmH 
This listing shows a more oittensira sample of an ASCII fSe that contains lists used as the starting point for 
List-Based Processmg. The list is intended only to show formats and relationships. It may not convey correct or 
5 complete medical mformation. The chief complaint for this eitenplary scr^t b "malaise". 

' MALARIA.TXT 

DEF H 
10 h_format 5 

h_complaint s^malaise 
END H 

DEF D 

15 d_falc "084.0" "Falciparum Malaria** 



s_tropics 200 

s_lethargic 100 

s_fever 200 

s_chills 200 

20 snochills -100 

s^sweats 200 

s_nosweats -100 

s_cfsinorder 200 

s_cf snotinorder 100 

25 s_2bouts_other 250 

s 3bouts other 250 
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sjpnotest 5 

sjpnegative -700 
e_pfalcip 700 

s_pvivax -700 

s_povale -700 

s_pmalar -700 

s_pmixed -700 



d_vivax "084.1" "Vivax Malaria" 



s_tropic6 200 

s_lethargic 100 

s_fever 2O0 

s_chills 200 

s_nochills -100 

s_sweats 200 

s_nosweats -100 

s_c f e inor de r 200 
s_cf snotinorder 100 

s_ 2 bou t s_4 8 350 

s_ 3 b ou t s_4 8 450 

s_pnotest 5 

s_pnega t i ve - 7 0 0 

s_pfalcip -700 

s_pvivax 700 

s_j)ovale -700 

s_pmalar -700 
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s_j)mixed -700 



d_quartan "084.2" "Quartan Malaria* 

s_tropics 200 

5 s_lethargic 100 

s_fever 200 

s_chills 200 

s_nochills -100 

s_sweats 200 

10 s_nosweats -100 

s_cfainorder 200 

s_cf snotinorder 100 

s_2bouts_72 350 

s_3boutS_72 450 

15 s_pnotest 5 

s_pnegative -70 0 

s_pfalcip -700 

s_pvivax -700 

s_povale -700 

20 s_pmalar 700 

8_pmixed -700 

d_ovale "084.3* "Ovale Malaria" 

s_tropics 200 

25 e_lethargic 100 

8 fever 200 
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s_chills 200 

s_nochills -100 

s_sweats 200 

s^nosweats -100 

6_c f s i nor de r 200 

s_cf snotinorder 100 

s_2bouts_other 250 

s_3bouts_other 350 

s_j)note8t 5 

e_pnegative -700 

s_pfalcip -700 

s j>vivax -700 

s_povale 700 

s_pmalar -700 

s^pmixed -700 



d_mixed "084.5" "Mixed Malaria" 



s^tropics 200 

s_lethargic 100 

s_fever 200 

s_chills 200 

s_nochill6 -100 

s_sweats 200 

s_noeweats -100 

s cfsinorder 200 



s_cf snotinorder 100 



10 



wo 98/02336 

s_lbout_23days 200 

s_lbout_other 200 

B_2bout smother 200 

s_3 bou t s_o t he r 300 

s_j>notest 5 

s_pnegative -700 

s^pfalcip -700 

s_pvivax -700 

s_povale -700 

s_pmalar -700 

s_pTnixed 700 



•3B. 
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d_unspec "084.6" "Malaria, unspec' 

s_tropics 200 

15 B_lethargic 100 

s_fever 200 

s_chills 200 

s_nochills -100 

s_sweats 200 

20 s_nosweats -100 

s_cfsinorder 200 

s_cf snotinorder 100 

s_pnote6t 100 



25 d_notmal "Not Malaria** 

s nofever 100 
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s^nochills 300 

s^nosweats 300 

s_nocf6 700 
s_cf snotinorder 3 00 

sjpnegative 1000 

s_pfalcip -600 

s_pvivax -600 

s_povale -600 

6_pmalar -600 

s_pmixed -600 
END D 



DBF S 



s_malaise 


0 


"general ill feeling** 


s_tropics 


f _tropics 


"recently in tropics" 


s_nottropics 


f^tropics 


"not 


recently in tropics" 


s^lethargic 


f_lethargic 


"has 


been tired/lethargic" 


s_not lethargic 


f_lethargic 


"not 


tired/lethargic" 


s_fever 


f_fever 


"has 


fever" 


s_no fever 


f_fever 


"has 


no fever" 


s_chills 


f_chills 


"has 


chills" 


s_nochills 


f_chills 


"has 


no chills" 


s_sweats 


f_sweats 


"has 


sweating" 


s_nosweats 


f_sweats 


"has 


no sweating" 


s_nocf s 


f_cfs 


"did 


not have CFS" 


s_cf sinorder 


f_cfs 


"had 


CFS" 
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15 



s_cf snotinorder f_cf s 

s_pnotest f_j>test 

s_pnegative f^jptest 

s_pfalcip f_pcest 

s_pvivax f_pte8t 

s_povale f_pte8t 

s_pmalar f_ptefit 

s_pmixed f_ptest 

s_lbout_lday f„cfs 

s_lbou t _2 3 days f _c f s 

s_lbout_other f _cf s • 

s_2bouts_48 fcfs 

s_2bouts_72 f_cfs 

6_2bout smother f_cf s 

s_3bouts_48 f_cfs 
s_3bouts_72 

s_3bout smother f s 
END S 
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"had CFS, but not in order" 
"not tested for Plasmodia" 
"plasm test negative" 
"teBt+ for P. falciparum" 
••test+ for P. vivax" 
"test+ for P, ovale" 
"test+ for P. malariae" 
"test+ for mixed Plasmodia" 
"1 CFS bout lasting 1 day" 
**1 CFS bout lasting 2-3 days" 
"1 cfs bout of vmk duration" 
"2 CFS bouts, 48h apart" 
"2 CFS bouts, 72h apart" 
"2 CFS bouts; unknown interval" 
"3+ CFS bouts every 48 hours" 
"3+ CFS bouts every 72 hours" 
"3^ CFS bouts of unk interval" 



20 DEF I 

s_nochills s_nocfs 

s_nof ever s_nocf s 

s_nosweats s_nocf s 

s_chillB s_fever s_sweats s_cfs 

25 END I 
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DEF F 
f^tropics 

"1" q_tropics 
"11" s_tropics 
" 12 " s_not tropics 
f_lethargic 

"1" q_lethargic 
" 11 " s_lethargic 
" 12 *• B_notlethargic 
f_f ever 

"1" q_fever 
"11" s_fever 
"12" s_nof ever 
f_chills 

"1" q_chills 
"11" s_chills 
"12" s_nochills 
f_sweats 

"l" q_sweats 
"11" s^sweats 
"12" s_nosweats 
f_cfs 

"1" q_cfs 
"12" s_nocf B 

"11" q[_c f sorder 

"112" s cf enotinorder 
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"111" q^cfsbouts 

"lllO" s_nocfs 

"1111" q_dlbout 

"11111" s_lbout_lday 
5 "11112" s_lbout_2 3days 

" 11113 " s_lbout_other 

"1112'* q_d2boutB 

"11121" s_2bout s_4 8 

"11122" eJ2 bou t s_7 2 
10 "11123" s_2 bou t s_o t he r 

"1113" q_d3bouts 

"11131" s_3bout s_4 8 

"11132" s_3bouts_72 

" 11133 " s_3bouts_other 
15 f jptest 

q_ptest 

"12" sjpnotest 

"11" q pfound 

"110" s_pnegative 
20 "111" s^pfalcip 

"112" s_pvivax 

"113" sjpovale 

"114 " s j)malar 

"115" s_pinixed 
25 END F 
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DEF Q 

q_tropics 0 t_qtropics 12 tkyes t_kno 

q_lethargic 0 t_glethargic 12 t_kyes t_kno 

q_fever 0 t_qfever 12 t_kyes t_kno 

q_chills 0 t_qchills 12 t_kyes t_kno 

q_sweats 0 t^qsweats 12 C_kyes t_kno 

q_cfs 0 t_qcfs 12 t_kyes t_kno 

q_cfsorder 0 t_qcfsorder 12 t_kyes t_kno 

q_pte6t 0 t_qptest 12 t_kyes t_kno 

qjpfound 0 t__qpfound 012345 t_knone t_falc t_viv t_ov t_mal t_mix 

q_cfsbouts 0 t_qcfsbouts 0123 t_knone t_kone t_ktwo t_k3plus 

q_dlbout 0 t_qdlbout 123 t_kuplday t_k23days tkother 

q_d2bouts 0 t_qd2bouts 123 t_k48hours t_k72hour6 t^kother 

q_d3bouts 0 t_qd3boute 123 t_k48hours t_k72hours t_kother 
END Q 



DEP T 

t_falc 
t_mal 
t_mix 
t_ov 
t viv 



FALCIPARUM 

MALARIAE 

MIXED 

OVALE 

VIVAX 



t_k23days 
t_k3plus 
t k48hours 



2-3 DAYS 
THREE+ 
4 6 HOURS 
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t_k72hours 

t_kno 

t_)cnone 

t_kone 

t^kother 

t_ktwo 

t_kuplday 

t_kyee 
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72 HOURS 
NO 

NONE 
ONE 
OTHER 
TWO 

UP TO ONE DAY 
YES 



10 t_qcfB 

t_qcf sbouts 
t_qcf sorder 
t_qchill6 
t_qdlbout 

15 t_qd2bouts 
t_qd3bouts 
t_q fever 
t_qlethargic 
t_qpf ound 

20 t_qptest 
t_qsweats 
t_qtropics 



Did you have Chills, Fever, and Sweating? 

How many bouts of C-F-S did you have? 

Did you have C-F-S in that order? 

Do you have chills? 

How long did that 1 bout last? 

What was the time between those 2 bouts? 

How far apart were these bouts? 

Do you have fever? 

Have you been tired or lethargic? 

What Plasmodia were found in blood? 

Did you have a blood test for Plasmodia? 

Do you have sweating? 

Have you been in the tropics recently? 



END T 



25 
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WHAT IS CLAIMED IS: 



1. 



A computerized diagnostic method* comprising the steps of: 



providmo to a computer a fist of diseases, each disease associated with a Sst of symptoms, and each 
symptom associated with a list of questions; 

repetitwely asking questions to eficit responses, the responses establishing symptoms, each established 
symptom contributing a weight to a disease; and 

determining whether the accumulated weights for a disease reach or pass a threshold so as to declare 
a diagnosis. 

2. The method defined in Claim 1. wherein the symptom is established based on the presence or absence 
of one or more other symptoms. 

3. The method defined in Claim 1, wherein the presence of a selected set of symptoms adds additional 
weight to a diagnosis. 

4. The method defined in Claim 1, wherein a symptom at a first selected time of the diagnostic process 
is weighted differently than the symptom at a second selected time of the process. 

5. The method defined in Claim 1, wherein the weight of a symptom reported at a first severity is 
different than the weight of the symptom reported at a second severity. 

6. The method defined in Claim 1, wherein a selected set of symptoms occurring in a specified sequence 
over time lends a different accumulated we'ght to the diagnosts than the accumulation of the individual weights of the 
selected set of symptoms not occurring in the specified sequence. 

7. The method defined in Claim 1. wherein a sequence of an onset or ending of a selected set of 
symptoms tends a different weight to the diagnosis than the eccumulated individual weights of the selected symptoms 



atone. 



B. 



The method defined in Claim 1, wherein the disease b ru!ed-in for further diagnostic inquiry based on 



the accumulated weight. 



9. 



The method defined in Claim 1, wherein the disease is ru!ed-out for further diagnostic inquiry based 



on the accumulated weight. 
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10. The method defmed in Claim 1, wherein questions for diseases deemed urgent are asked before 
questions for non-urgent diseases. 

11. The method defined in Claim 1, additionally comprising the step of determining whether the 
accumulated weights for a disease are less than a rute-out threshold so as to eliminate a possible diagnosis. 

12. The method defined in Cfa'mn 8, wherein a degree of certainty of ruling-tn the disease is provided. 

13. The method defined in Claim 9, wherein a degree of certainty of ruling out the disease is provided. 

14. The method defined in Claim 1, wherein a pturaity of diagnoses, each diagnosis having a degree of 
certainty, are accumulated into a differential diagnosis fist. 
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I 

V 
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ASSISTED LOGIN 



ASSISTANT LOGIN 



PATIENT LOGIN 
PROCESS 



ASSISTED 
REGISTRATION 



ASSISTANT 
REGISTRATION 



PATIENT 
REGISTRATION 
PROCESS 



DIAGNOSTIC 
PROCESS 



SCRIPT 
ENGINE 



META 



n FUTURE II 
LI IJ 





MSE 








SDER 








PMH 








PSE 








PMC 








SSA 





220 



SOFTWARE STRUCTURES 



Read/ 
Write 




PATIENT AND 
ASSISTANT 
ENROLLMENT 
DATABASE 



240 



Reod/ 
Write 

Write 



Reod 



Read/ 
Write 




Write 



Reod/ 
Write 



CONSULTATION 
HISTORY 



PATIENT 
RESPONSE 



MEDICAL HISTORY 
OBJECTS 



PATIENT 
MEDICATION 



PENDING RLE 



PATIENT MEDICAL 
HISTORY 



242 




Reod 



Read 



Read 



MDS DATABASE 




IMAGING MODALITY 
OF CHOICE 



LABORATORY TEST 
OF CHOICE 



'254 



256 



'253 



'260 



SUBSTITUTE SHEET (RULE 26) 
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J20 



5/20 

TIME - BASED DSQ LISTS 



SCRIPT I - TIME: T 



J24 



DISEASE A 



DISEASE B 




DISEASE X 



SYMPTOM A1 
J26^ 

SYMPTOM A2- 

O 

o 

SYMPTOM Ay 
SYMPTOM B1 

O 

o 
o 

SYMPTOM By 
SYMPTOM x1 

O 

o 
o 

SYMPTOM wy 





^J23 

QUESTION Ala 
QUESTION Alb 

o 
o 
o 

•QUESTION Al2 

QUESTION A2a 
QUESTION A2b 

O 

o 
e 

QUESTION A2z 
QUESTION Ayo 

O 

o 

9 

QUESTION Ayz 
QUESTION B1a 



QUESTION Biz 
QUESTION Byo 



QUESTION Byz 
QUESTION xta 

O 

o 

o 

QUESTION xlz 
QUESTION »ya 



QUESTION «yz 



J22 



\ 

SCRIPT I - TIME: Tj 



DISEASE A 



DISEASE B 




DISEASE X 



SYMPTOM A1 



SYMPTOM A2'^ 



SYMPTOM Ay 



SYMPTOM Bt 



SYMPTOM By 




SYMPTOM x1 



SYMPTOM xy 



SUBSTiTUTE SHEET (RULE 26) 



•QUESTION Ala' 
QUESTION Alb 



O 

o 
o 




"QUESTION Alz* 

-QUESTION A2a 
•QUESTION A2b* 

O 

o 
o 

QUESTION A2z 
QUESTION Aya 



QUESTION Ayz' 
QUESTION Bla 

O 

o 
o 

QUESTION Biz 
QUESTION Byo 



QUESTION Byz 
•QUESTION xlo' 



c 



■QUESTION Klz* 
QUESTION xya 



QUESTION xyz 
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ASSIGN DISEASES 



START 
ASSIGNMENT OF 
DISEASES 




J52 
J54 



J30 
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